TypeScript autentifikācija: JWT tipu drošības modeļi globālām lietojumprogrammām

Mūsdienu savstarpēji saistītajā pasaulē ir ārkārtīgi svarīgi izveidot drošas un uzticamas globālas lietojumprogrammas. Autentifikācijai, lietotāja identitātes pārbaudes procesam, ir būtiska loma sensitīvu datu aizsardzībā un pilnvarotas piekļuves nodrošināšanā. JSON Web Tokens (JWT) ir kļuvuši par populāru izvēli autentifikācijas ieviešanai, pateicoties to vienkāršībai un pārnesamībai. Apvienojot ar TypeScript jaudīgo tipu sistēmu, JWT autentifikāciju var padarīt vēl robustāku un uzturamāku, īpaši liela mēroga starptautiskiem projektiem.

Kāpēc izmantot TypeScript JWT autentifikācijai?

TypeScript piedāvā vairākas priekšrocības, veidojot autentifikācijas sistēmas:

• Tipu drošība: TypeScript statiskā tipēšana palīdz atrast kļūdas agrīnā izstrādes procesā, samazinot risku, ka darbības laikā būs pārsteigumi. Tas ir ļoti svarīgi drošībai jutīgiem komponentiem, piemēram, autentifikācijai.
• Uzlabota koda uzturamība: tipi nodrošina skaidrus līgumus un dokumentāciju, atvieglojot koda izpratni, modificēšanu un pārveidošanu, īpaši sarežģītās globālās lietojumprogrammās, kur var būt iesaistīti vairāki izstrādātāji.
• Uzlabota koda pabeigšana un rīki: TypeScript informētas IDE piedāvā labāku koda pabeigšanu, navigāciju un pārveidošanas rīkus, palielinot izstrādātāju produktivitāti.
• Samazināts šablonu kods: tādas funkcijas kā saskarnes un ģeneriskie tipi var palīdzēt samazināt šablonu kodu un uzlabot koda atkārtotu izmantošanu.

JWT izpratne

JWT ir kompakts, URL drošs veids, kā attēlot prasības, kas jāpārnes starp divām pusēm. Tas sastāv no trim daļām:

1. Galvene: norāda algoritmu un marķiera tipu.
2. Payload: satur prasības, piemēram, lietotāja ID, lomas un derīguma termiņu.
3. Paraksts: nodrošina marķiera integritāti, izmantojot slepenu atslēgu.

JWT parasti tiek izmantoti autentifikācijai, jo tos var viegli pārbaudīt servera pusē, nepieprasot datu bāzi katram pieprasījumam. Tomēr parasti nav ieteicams glabāt sensitīvu informāciju tieši JWT payload.

Tipu drošas JWT autentifikācijas ieviešana TypeScript

Izpētīsim dažus modeļus tipu drošu JWT autentifikācijas sistēmu veidošanai TypeScript.

1. Payload tipu definēšana ar saskarnēm

Sāciet ar saskarnes definēšanu, kas attēlo jūsu JWT payload struktūru. Tas nodrošina tipu drošību, piekļūstot prasībām marķierī.

interface JwtPayload {
  userId: string;
  email: string;
  roles: string[];
  iat: number; // Izdots (laika zīmogs)
  exp: number; // Derīguma termiņš (laika zīmogs)
}

Šī saskarne definē paredzamo JWT payload formu. Mēs esam iekļāvuši standarta JWT prasības, piemēram, `iat` (izdots) un `exp` (derīguma termiņš), kas ir ļoti svarīgas marķiera derīguma pārvaldībai. Jūs varat pievienot jebkuras citas prasības, kas ir svarīgas jūsu lietojumprogrammai, piemēram, lietotāju lomas vai atļaujas. Ir laba prakse ierobežot prasības tikai ar nepieciešamo informāciju, lai samazinātu marķiera lielumu un uzlabotu drošību.

Piemērs: Lietotāju lomu apstrāde globālā e-komercijas platformā

Apsveriet e-komercijas platformu, kas apkalpo klientus visā pasaulē. Dažādiem lietotājiem ir dažādas lomas:

• Administrators: Pilna piekļuve produktu, lietotāju un pasūtījumu pārvaldībai.
• Pārdevējs: Var pievienot un pārvaldīt savus produktus.
• Klients: Var pārlūkot un iegādāties produktus.

`roles` masīvu `JwtPayload` var izmantot, lai attēlotu šīs lomas. Jūs varētu paplašināt `roles` īpašību uz sarežģītāku struktūru, kas smalki attēlo lietotāja piekļuves tiesības. Piemēram, jums varētu būt valstu saraksts, kurās lietotājam ir atļauts darboties kā pārdevējam, vai veikalu masīvs, kam lietotājam ir administratora piekļuve.

2. Tipizēta JWT pakalpojuma izveide

Izveidojiet pakalpojumu, kas apstrādā JWT izveidi un pārbaudi. Šim pakalpojumam jāizmanto `JwtPayload` saskarne, lai nodrošinātu tipu drošību.

import jwt from 'jsonwebtoken';

const JWT_SECRET = process.env.JWT_SECRET || 'your-secret-key'; // Glabājiet droši!

class JwtService {
  static sign(payload: Omit, expiresIn: string = '1h'): string {
    const now = Math.floor(Date.now() / 1000);
    const payloadWithTimestamps: JwtPayload = {
        ...payload,
        iat: now,
        exp: now + parseInt(expiresIn) * 60 * 60,
    };
    return jwt.sign(payloadWithTimestamps, JWT_SECRET);
  }

  static verify(token: string): JwtPayload | null {
    try {
      const decoded = jwt.verify(token, JWT_SECRET) as JwtPayload;
      return decoded;
    } catch (error) {
      console.error('JWT verification error:', error);
      return null;
    }
  }
}

Šis pakalpojums nodrošina divas metodes:

• `sign()`: Izveido JWT no payload. Tam ir nepieciešams `Omit`, lai nodrošinātu, ka `iat` un `exp` tiek automātiski ģenerēti. Ir svarīgi droši glabāt `JWT_SECRET`, ideālā gadījumā izmantojot vides mainīgos un slepenības pārvaldības risinājumu.
• `verify()`: Pārbauda JWT un atgriež dekodētu payload, ja tas ir derīgs, vai `null`, ja tas nav derīgs. Mēs izmantojam tipa apgalvojumu `as JwtPayload` pēc pārbaudes, kas ir droša, jo metode `jwt.verify` vai nu izraisa kļūdu (noķerta `catch` blokā), vai atgriež objektu, kas atbilst mūsu definētajai payload struktūrai.

Svarīgi drošības apsvērumi:

• Slepeno atslēgu pārvaldība: Nekad neiekodējiet savu JWT slepeno atslēgu savā kodā. Izmantojiet vides mainīgos vai īpašu slepenības pārvaldības pakalpojumu. Regulāri rotējiet atslēgas.
• Algoritma izvēle: Izvēlieties spēcīgu parakstīšanas algoritmu, piemēram, HS256 vai RS256. Izvairieties no vājiem algoritmiem, piemēram, `none`.
• Marķiera derīguma termiņš: Iestatiet atbilstošus derīguma termiņus saviem JWT, lai ierobežotu kompromitētu marķieru ietekmi.
• Marķiera glabāšana: Droši glabājiet JWT klienta pusē. Iespējas ietver HTTP tikai sīkfailus vai lokālo krātuvi ar atbilstošiem piesardzības pasākumiem pret XSS uzbrukumiem.

3. API galapunktu aizsardzība ar starpprogrammatūru

Izveidojiet starpprogrammatūru, lai aizsargātu savus API galapunktus, pārbaudot JWT galvenē `Authorization`.

import { Request, Response, NextFunction } from 'express';

interface RequestWithUser extends Request {
  user?: JwtPayload;
}

function authenticate(req: RequestWithUser, res: Response, next: NextFunction) {
  const authHeader = req.headers.authorization;

  if (!authHeader) {
    return res.status(401).json({ message: 'Unauthorized' });
  }

  const token = authHeader.split(' ')[1]; // Pieņemot Bearer marķieri
  const decoded = JwtService.verify(token);

  if (!decoded) {
    return res.status(401).json({ message: 'Invalid token' });
  }

  req.user = decoded;
  next();
}

export default authenticate;

Šī starpprogrammatūra izvelk JWT no galvenes `Authorization`, pārbauda to, izmantojot `JwtService`, un pievieno dekodētu payload objektam `req.user`. Mēs arī definējam saskarni `RequestWithUser`, lai paplašinātu standarta `Request` saskarni no Express.js, pievienojot `user` rekvizītu ar tipu `JwtPayload | undefined`. Tas nodrošina tipu drošību, piekļūstot lietotāja informācijai aizsargātos maršrutos.

Piemērs: Laika zonu apstrāde globālā lietojumprogrammā

Iedomājieties, ka jūsu lietojumprogramma ļauj lietotājiem no dažādām laika zonām plānot notikumus. Iespējams, vēlēsities saglabāt lietotāja vēlamo laika zonu JWT payload, lai pareizi parādītu notikumu laikus. Jūs varētu pievienot `timeZone` prasību `JwtPayload` saskarnei:

interface JwtPayload {
  userId: string;
  email: string;
  roles: string[];
  timeZone: string; // piem., 'America/Los_Angeles', 'Asia/Tokyo'
  iat: number;
  exp: number;
}

Pēc tam savā starpprogrammatūrā vai maršruta apdarinātājos varat piekļūt `req.user.timeZone`, lai formatētu datumus un laikus atbilstoši lietotāja vēlmēm.

4. Autentificēta lietotāja izmantošana maršruta apdarinātājos

Savos aizsargātajos maršruta apdarinātājos tagad varat piekļūt autentificēta lietotāja informācijai, izmantojot objektu `req.user`, ar pilnu tipu drošību.

import express, { Request, Response } from 'express';
import authenticate from './middleware/authenticate';

const app = express();

app.get('/profile', authenticate, (req: Request, res: Response) => {
  const user = (req as any).user; // vai izmantojiet RequestWithUser
  res.json({ message: `Sveiki, ${user.email}!`, userId: user.userId });
});

Šis piemērs parāda, kā piekļūt autentificēta lietotāja e-pastam un ID no objekta `req.user`. Tā kā mēs definējām saskarni `JwtPayload`, TypeScript zina paredzamo `user` objekta struktūru un var nodrošināt tipu pārbaudi un koda pabeigšanu.

5. Lomas balstītas piekļuves kontroles (RBAC) ieviešana

Lai iegūtu detalizētāku piekļuves kontroli, varat ieviest RBAC, pamatojoties uz lomām, kas saglabātas JWT payload.

function authorize(roles: string[]) {
  return (req: RequestWithUser, res: Response, next: NextFunction) => {
    const user = req.user;

    if (!user || !user.roles.some(role => roles.includes(role))) {
      return res.status(403).json({ message: 'Forbidden' });
    }

    next();
  };
}

Šī `authorize` starpprogrammatūra pārbauda, vai lietotāja lomās ir kāda no nepieciešamajām lomām. Ja nē, tā atgriež 403 Aizliegtu kļūdu.

app.get('/admin', authenticate, authorize(['admin']), (req: Request, res: Response) => {
  res.json({ message: 'Laipni lūdzam, Administrator!' });
});

Šis piemērs aizsargā maršrutu `/admin`, pieprasot, lai lietotājam būtu `admin` loma.

Piemērs: Dažādu valūtu apstrāde globālā lietojumprogrammā

Ja jūsu lietojumprogramma apstrādā finanšu darījumus, iespējams, jums būs jāatbalsta vairākas valūtas. Jūs varētu saglabāt lietotāja vēlamo valūtu JWT payload:

interface JwtPayload {
  userId: string;
  email: string;
  roles: string[];
  currency: string; // piem., 'USD', 'EUR', 'JPY'
  iat: number;
  exp: number;
}

Pēc tam savā backend loģikā varat izmantot `req.user.currency`, lai formatētu cenas un veiktu valūtas konvertācijas pēc vajadzības.

6. Atjaunošanas marķieri

JWT ir paredzēti īslaicīgi. Lai izvairītos no tā, ka lietotājiem bieži jāpiesakās, ieviesiet atjaunošanas marķierus. Atjaunošanas marķieris ir ilgstošs marķieris, ko var izmantot, lai iegūtu jaunu piekļuves marķieri (JWT), nepieprasot lietotājam atkārtoti ievadīt savus akreditācijas datus. Droši glabājiet atjaunošanas marķierus datu bāzē un saistiet tos ar lietotāju. Kad lietotāja piekļuves marķiera derīguma termiņš beidzas, viņi var izmantot atjaunošanas marķieri, lai pieprasītu jaunu. Šis process jāīsteno rūpīgi, lai izvairītos no drošības ievainojamībām.

Uzlabotas tipu drošības metodes

1. Diskriminēti apvienojumi detalizētai kontrolei

Dažreiz jums var būt nepieciešami dažādi JWT payload, pamatojoties uz lietotāja lomu vai pieprasījuma veidu. Diskriminēti apvienojumi var palīdzēt jums to panākt ar tipu drošību.

interface AdminJwtPayload {
  type: 'admin';
  userId: string;
  email: string;
  roles: string[];
  iat: number;
  exp: number;
}

interface UserJwtPayload {
  type: 'user';
  userId: string;
  email: string;
  iat: number;
  exp: number;
}

type JwtPayload = AdminJwtPayload | UserJwtPayload;

function processToken(payload: JwtPayload) {
  if (payload.type === 'admin') {
    console.log('Administratora e-pasts:', payload.email); // Droši piekļūt e-pastam
  } else {
    // payload.email šeit nav pieejams, jo tips ir 'user'
    console.log('Lietotāja ID:', payload.userId);
  }
}

Šis piemērs definē divus dažādus JWT payload tipus, `AdminJwtPayload` un `UserJwtPayload`, un apvieno tos diskriminētā apvienojumā `JwtPayload`. Īpašība `type` darbojas kā diskriminators, ļaujot droši piekļūt īpašībām, pamatojoties uz payload tipu.

2. Ģeneriskie tipi atkārtoti izmantojamai autentifikācijas loģikai

Ja jums ir vairākas autentifikācijas shēmas ar dažādām payload struktūrām, varat izmantot ģeneriskos tipus, lai izveidotu atkārtoti izmantojamu autentifikācijas loģiku.

interface BaseJwtPayload {
  userId: string;
  iat: number;
  exp: number;
}

function verifyToken(token: string): T | null {
  try {
    const decoded = jwt.verify(token, JWT_SECRET) as T;
    return decoded;
  } catch (error) {
    console.error('JWT verification error:', error);
    return null;
  }
}

const adminToken = verifyToken('admin-token');
if (adminToken) {
  console.log('Administratora e-pasts:', adminToken.email);
}

Šis piemērs definē funkciju `verifyToken`, kas pieņem ģenerisku tipu `T`, kas paplašina `BaseJwtPayload`. Tas ļauj pārbaudīt marķierus ar dažādām payload struktūrām, vienlaikus nodrošinot, ka tiem visiem ir vismaz īpašības `userId`, `iat` un `exp`.

Globālas lietojumprogrammas apsvērumi

Veidojot autentifikācijas sistēmas globālām lietojumprogrammām, apsveriet šādus aspektus:

• Lokalizācija: Nodrošiniet, lai kļūdu ziņojumi un lietotāja interfeisa elementi būtu lokalizēti dažādām valodām un reģioniem.
• Laika zonas: Pareizi apstrādājiet laika zonas, iestatot marķiera derīguma termiņus un parādot datumus un laikus lietotājiem.
• Datu privātums: Ievērojiet datu privātuma noteikumus, piemēram, GDPR un CCPA. Samaziniet personisko datu apjomu, kas tiek glabāts JWT.
• Pieejamība: Izstrādājiet savas autentifikācijas plūsmas tā, lai tās būtu pieejamas lietotājiem ar invaliditāti.
• Kultūras jutīgums: Esiet uzmanīgi pret kultūras atšķirībām, izstrādājot lietotāja interfeisus un autentifikācijas plūsmas.

Secinājums

Izmantojot TypeScript tipu sistēmu, varat izveidot robustas un uzturamas JWT autentifikācijas sistēmas globālām lietojumprogrammām. Payload tipu definēšana ar saskarnēm, tipizētu JWT pakalpojumu izveide, API galapunktu aizsardzība ar starpprogrammatūru un RBAC ieviešana ir būtiski soļi, lai nodrošinātu drošību un tipu drošību. Apsverot globālas lietojumprogrammas apsvērumus, piemēram, lokalizāciju, laika zonas, datu privātumu, pieejamību un kultūras jutīgumu, varat izveidot autentifikācijas pieredzi, kas ir iekļaujoša un lietotājam draudzīga daudzveidīgai starptautiskai auditorijai. Atcerieties vienmēr par prioritāti drošības labākajai praksei, apstrādājot JWT, ieskaitot drošu atslēgu pārvaldību, algoritma izvēli, marķiera derīguma termiņu un marķiera glabāšanu. Izmantojiet TypeScript jaudu, lai izveidotu drošas, mērogojamas un uzticamas autentifikācijas sistēmas savām globālajām lietojumprogrammām.